A multi-party communication is a communication scenario in which two or more members participate. A communication scenario in which only two members participate is a special case of the multi-party communication. The multi-party communication scenario generally includes a plurality of data receivers and one or more data senders. In the multi-party communication, a message may be sent using unicast technology or multicast technology and it is easier to implement the multi-party communication using the multicast technology than the unicast technology.
Typical multi-party communication scenarios include a remote multi-party conference, an IP telephony, an IPTV, a network on-line gaming, a grid computing, etc. The security of multi-party communication includes access control (authorization and authentication) of multi-party communication participators and security services such as encryption, integrity protection, replay protection, source authentication, and group authentication of communication contents that are used to prevent one other than a group member of the multi-party communication from intercepting and tampering with the communication contents or interfering with the normal communication and which further eliminate a threat to security caused by an internal group member of the multi-party communication.
Requirements on the security of multi-party communication primarily may include:
1. Authorization and authentication. A user may participate in a multi-party communication group and may receive/send data only if the user is authorized and authenticated so that the multi-party communication group is controllable.
2. Secrecy. A node may decrypt the contents of a group communication message only if the node has the decryption key.
3. Authentication of group member. A non-group member cannot generate valid authentication information, and therefore cannot impersonate a group member to send a multicast message.
4. Source authentication (anti-denial). A group member cannot generate the authentication information of another group member, and therefore cannot impersonate another group member to send a multicast message. On the other hand, the group member cannot deny the information sent by the group member.
5. Anonymity. A group member is provided with a mechanism of speaking anonymously. In other words, a receiving party cannot determine the identity of the sending party from the received multicast message.
6. Integrity. A means for verifying whether a received multicast message is tampered.
7. Anti-replay. A replay detecting mechanism is provided to implement the anti-replay attack.
Generally, in order to ensure the security of multi-party communication, a multi-party communication message is transmitted in an encrypted form. A multi-party shared key for encryption and decryption is known to group members only, thus ensuring that only the group members may decrypt the encrypted message. The multi-party shared key can also be used to implement the authentication of group member because only the group member having the multi-party shared key can generate the encrypted multicast message correctly.
The implementation of the security of multi-party communication using the above-mentioned multi-party shared key depends on the generating and distributing of the key. The generation and distribution of the key must be exclusive. In other words, a non-group m ember cannot get the generated and distributed key. Generally, the source authentication, the integrity, and the anonymity also need the exclusive sharing of secret information among two or more parties. In the multi-party communication, how to achieve the exclusive sharing of key is a group key management research topic where the group key is a secret shared by all the group members and is used for security operations such as encryption and decryption on a multicast message. The research on group key management focuses on how to generate, distribute, and update a group key for group members and further how to address the problems of scalability, robustness, and reliability.
In the prior art, a solution for implementing the security of multi-party communication includes a management solution using the Multicast Security (MSEC) protocol suite designed by the MSEC working group. As a working group under the Internet Engineering Task Force (IETF) security area, the MSEC is dedicated to the IP multicast security and has established several security protocols. The schematic diagram of the operation of the MSEC protocol suite is shown in FIG. 1.
The design concept of the protocols by the MSEC working group is to separate the group key management from the data security and focus on the group key management. The MSEC working group has already standardized a plurality of group key management protocols including the Group Secure Association Key Management Protocol (GSAKMP), the Group Domain of Interpretation (GDOI), the Multimedia Internet Key management (MIKEY), and the like. All of these protocols tend to provide a standard group key management solution for a data security protocol based on multicast.
In terms of operation mode, the MSEC protocol suite is relatively suitable for operating in a n environment supporting IP-layer multicast. F or example, the GSAKMP protocol and the GDOI protocol simply utilize the group key management algorithm requiring a multicast service. Although such a group key management algorithm may operate based on unicast, the operating efficiency is severely affected. However, no optimized measure is specified for substituting the multicast mode with the unicast mode in the above two protocols. In addition, the MIKEY protocol also needs to utilize the multicast operation mode when operating in the multi-party communication mode.
In terms of the supported data security protocols, the MSEC protocol suite is scalable whereas the MSEC protocol suite mainly supports the Encapsulating Security Payload (ESP) protocol and the Authentication Header (AH) protocol which operate at the IP layer, and the data security service of multi-party communication is provided in the multicast mode only.
Examples of the ways in which the above management solution of the MSEC protocol suite designed by the SEC working group is disadvantageous are described below.
1. It is difficult to provide a standard Application Program Interface (API) to an application program and an application protocol.
A group key management protocol and a data security protocol are designed to be separate from each other in the MSEC protocol suite. Each group key management protocol, such as the GDOI protocol and the GSAKMP protocol, may only operate individually as a daemon or an application program and cannot provide the application program with a set of standard APIs to control the group key management. Therefore, in this solution, the application program developed based on the group key management protocol has poor portability.
Further, the operation of the MIKEY protocol requires the MIKEY protocol to be embedded into an application program employing the service of the MIKEY protocol. In other words, the application program may employ the function of the MKEY protocol only if the application program implements by itself the interaction process of the MIKEY protocol which increases the coupling degree between the MIKEY protocol and the application program so that each programmer has to possess acknowledge of the internal implementation of the MIKEY protocol to use the functions of the MIKEY protocol, resulting in more difficulties in implementing the application program.
In terms of the data security, the MSEC protocol suite mainly supports the ESP protocol and the AH protocol at present, both of which are implemented at the IP layer and need to operate within the core of an operating system. Accordingly, such a way of implementation results in not only poor program portability because no standard API for data security can be provided, but also the impact on the deployment of an application program because various operating systems have different supportabilities of the ESP protocol and the AH protocol and even some of the operation systems cannot support the ESP protocol and the AH protocol. In practice, only systems of Windows, Linux, Unix, and some special-purpose network devices such as a firewall support the IPsec. Other systems such as mobile phones and small scale routers rarely support the IPsec.
Furthermore, even though the MSEC protocol suite may support a new data security protocol after extension, the service provided by the MSEC protocol suite cannot be utilized by an application program due to lack of a general data security protocol which may be invoked directly by the application program and support the multi-party communication.
2. The implementation is based on a centralized management mode and does not support the distributed key negotiation.
The MSEC protocol suite is dependant upon a key server to implement the security of multi-party communication with more than two parties and therefore does not support the purely distributed multi-party communication scenario in a peer-to-peer (P2P) network and the like.
3. The system is very complicated and is very difficult to be implemented.
The MSEC is derived from the IPsec which is a system for providing a data security service at the IP layer. This data security service is end-to-end other than process-to-process. The IPsec may provide the end-to-end data security service in various modes su ch as host-to-host, host-to-gateway, and gateway-to-gateway. In addition, in order to support a VPN function, the data security is implemented in two separated modes in the IPsec, i.e., a tunnel mode and a transport mode, and the tunnel mode is used for implementing an IPsec tunnel.
Accordingly, an IPsec system is very large and complicated as a result of the above implementation mode and requirements. There are more than ten RFCs on the IPsec only, covering the aspects of system architecture, key management, data security, algorithm description, and the like. Because of the complexity, there are few implementations of the entire IPsec in practice. Currently, the IPsec is supported primarily in some popular operating systems (such as Windows, Linux, and Unix), and special-purpose network devices such as a firewall and some high-end routers. In addition, the IPsec tends to be used for the IPsec VPN in the industry at present.
Similarly, the MSEC is not suitable for implementing the process-to-process data security service due to inheriting the above characteristics (or disadvantages).
4. The data security service is implemented at the IP layer, and no data protection function with a granularity finer than quintuple can be provided.
The IPsec filters messages using the quintuple to select a message needing to be protected and performs the encryption and integrity protection on the selected message. However, the granularity of quintuple of the IPsec is not fine enough to identify precisely the particular session of an application. For those P2P Overlay platforms re-constituting their own protocol stacks over the TCP/IP protocol stack, the mechanism of quintuple of the IPsec cannot even identify an application on these platforms and therefore cannot provide the data security service at the application-to-application level for the P2P Overlay platforms. These disadvantages are inherited by the MSEC.
When operating in connection with a data security protocol of Secure Real-time Transport Protocol (SRTP), the MSEC may offer a data security service at the level as fine as an Real-time Transport Protocol (RTP) Session. However, the SRTP is constituted especially for the RTP and is not a general data security protocol.
In the prior art, another solution of implementing the security of multi-party communication is a solution of security of two-party communication based on the Transport Layer Security (TLS, a security protocol based on a reliable connection-oriented transmission) and the Wireless Transport Layer Security (DTLS, a security protocol based on an unreliable connectionless transmission) technologies.
The TLS and the DTLS operate between an application layer and a transport layer, enabling to provide a standard API for an application program so that the application program may invoke the standard API and control the function of the TLS and the DTLS. Further, the TLS and the DTLS operate in the application program process space, allowing easy interaction with the application program. The TLS and DTLS operate in a Client/Server mode and may provide security functions such as authentication, key negotiation, key update, encryption, integrity protection, and anti-replay.
The above solution of security of two-party communication based upon the TLS and DTLS has at least the following disadvantages described herein. To be specific, this solution may provide a security service for a communication with only two parties. For a communication scenario with three or more parties, the security service may be provided only through an approach of establishing multiple sessions which has a very low feasibility due to its complexity and low efficiency.